I was connecting to a Jupiter and got an FID type "pending". Anyone know what that represents?

Hey, someone got you a connection! Cool.

I don't know for sure, this is just a wild guess, but I'll bet that's a track that hasn't yet been compiled into an MP3 yet. The player assigns FIDs to tracks that were ripped and are now waiting for the background process to get around to encoding them. Dial back in in a few minutes and it'll probably be a more normal FID type.

That's my guess, anyway...

Yeah -- Very cool ... So preliminarily, I was able to connect and download the database and everything looked cool (of course, jEmplode then added Unattached Items ). I was able to sync that and everything worked. Then I tried to add a tune and sync and the protocol started failing and sending me NAKs ... My connection here is kind of flaky, so it's hard to tell exactly what the deal was.

So the interesting thing is that this sounds different than what you saw, if I recall correctly. Can you describe a little more about what you saw when you connected?

Mike

Nothing. Literally. No soup, just playlists (which are only a subset of the tunes on the player).

Remember that the jupe is designed to be used completely without playlists at all, and Soups are the default method of playing things.

I can't remember what we tried when we were talking before, but the new jEmplode doesn't default to having any soups installed... You may want to add a New Soup Playlist and use the "All" one. The thing I'm most curious/concerned about with your situation was the fact that there were tunes that started to be removed when you synced. I'm very curious why that was.... I haven't seen that behavior yet with the latest build using Shawn's Jupiter.

I'm retrying that sync to his Jupe now with tons of debugging enabled. It actually appears that my connection is so lame now that it's actually timing out between upload packets (timeout time is set to 5 seconds, but during an upload the packets can be big enough that it times out). After a couple retries it actually ends up working. So basically, what I'm saying is that the latest build appears to be working properly with this Jupiter.

Given this very basic appearance of success, I may give you a debug-enabled build to try out and I'll just grab all your logs ... I'll make a version that doesn't actually sync for you but instead prints out what it _would_ have done (so you can see if it would have attempted to remove a tune and why).

Mike

I can't remember what we tried when we were talking before, but the new jEmplode doesn't default to having any soups installed... You may want to add a New Soup Playlist and use the "All" one.

Okay, first of all... If you want Jemplode to work as an Emplode replacement, I think you should see the built-in soup views by default (like Emplode does) and not have to create playlists for them.

And... when I tried that before, it didn't work (no soups appeared) and that's when it started deleting my files (and I downgraded. ).

Given this very basic appearance of success, I may give you a debug-enabled build to try out and I'll just grab all your logs ... I'll make a version that doesn't actually sync for you but instead prints out what it _would_ have done (so you can see if it would have attempted to remove a tune and why).

I'd love to do that. If I'm online later tonight, hit me up on Instant Messenger and we can pound on it together.

Ahh... the soups hosed you. Interesting. I don't know if I'll get to it tonight, but maybe sometime tomorrow if you're free? I'll try to add that debugging stuff in sometime between now and then.

http://jempeg.sourceforge.net/jemplode-debug.jar

go into your .jempegrc and add:
jempeg.readOnly=true
and
jempeg.debugLevel=28
(28 = Error + Warning + Informative) The output should show a bunch of info. Among the info should be a bunch of ### READ-ONLY: xxxx lines that say what it _would_ have been doing if you had write access turned on. Any time that it replaces a tune with an FIDDeleted (i.e. attempts to delete a node) it will spit out a full stack trace that shows the calling trace of who attempted to delete it. If you can fire up jEmplode on your Jupiter, create a soup playlist, the sync and save all that output to a file and send it to me, maybe I can tell what's going on.

You may want to test this out on your Empeg to make sure it's properly printing out the READ-ONLY strings (wouldn't want you to find out that i uploaded the wrong version by deleting everything off your Jupiter ).

Mike

OK -- I stuck in autocreation of soups in 46.

The player assigns FIDs to tracks that were ripped and are now waiting for the background process to get around to encoding them.

If they've been ripped but not encoded, that means they're WAVs and can be played and jemploded just like any other tune. "Pending" means the FID has been allocated, but not yet used: the most common cause of this is when you start ripping a track from CD but ripping is interrupted -- perhaps by an unreadable-CD error, or by the user cancelling the operation. If you are sure no ripping is going on then it is safe to delete pending FIDs -- they would go away when the database was rebuilt anyway. Or you could just ignore them.

Peter